Passive crowd-sourced map updates and alternate route recommendations

ABSTRACT

Systems and methods for providing passive crowd-sourced alternate route recommendations. In one embodiment, locations of users of a number of mobile location-aware devices are tracked over time. Upon receiving a request, users of mobile location-aware devices that have traveled from a desired start location to a desired stop location are identified. Location histories for the identified users are analyzed to determine one or more different routes taken from the desired start location to the desired stop location. The one or more different routes, or a select subset thereof, are then returned to the requestor as recommended alternate routes.

RELATED APPLICATIONS

This application claims the benefit of provisional patent applicationSer. No. 61/163,091, filed Mar. 25, 2009, the disclosure of which ishereby incorporated herein by reference in its entirety.

FIELD OF THE DISCLOSURE

The present disclosure relates to crowd-sourced map updates andcrowd-sourced alternate route recommendations.

BACKGROUND

Personal Navigation Devices (PNDs) often have maps that are out-of-date.Traditional mechanisms for updating the maps of PNDs are cumbersome andinconvenient. More specifically, traditionally companies such as NAVTEQcollect information regarding roads by driving every road usingspecially equipped cars. These companies then provide the collectedinformation to PND providers for use in their maps. Recently, TomTom hasintroduced a service referred to as Map Share that enables users ofTomTom® PNDs to manually make corrections to their maps and then sharetheir corrections with other users of the TomTom® Map Share service.However, even though the TomTom® Map Share service provides someadvantages, it is still cumbersome and burdensome on the users in thatthey must manually make corrections to their maps. As such, there is aneed for a system and method for updating the maps of PNDs that placeslittle, if any, burden on users of the PNDs. In addition, an improvedsystem and method for providing alternate route recommendations to usersis needed.

SUMMARY

Systems and methods for providing passive crowd-sourced alternate routerecommendations are disclosed. In one embodiment, locations of users ofa number of mobile location-aware devices are tracked over time. Uponreceiving a request for alternate routes from a requestor, users ofmobile location-aware devices that have traveled from a start locationidentified by the request to a stop location identified by the requestare identified. Location histories for the identified users are analyzedto determine one or more routes taken by the users from the startlocation to the stop location. The one or more routes, or a selectsubset of the one or more routes, are then returned to the requestor asrecommended alternate routes. In addition, one or more characteristicsof the recommended alternate routes may be determined and returned tothe requestor. For each recommended alternate route, the one or morecharacteristics may include, for example, an average travel time for therecommended alternate route, an average travel time for the recommendedalternate route for a desired time window, a number of users that havepreviously traveled the recommended alternate route, or the like.

In addition, systems and methods for providing passive crowd-sourced mapupdates are disclosed. In one embodiment, locations of users of a numberof mobile location-aware devices are tracked over time. The locations ofthe users of the mobile location-aware devices are analyzed with respectto a map data model defining a map to detect a travel pattern that isindicative of an update that should be made to the map. An update thatreflects the detected travel pattern is then added to the map via themap data model. In one embodiment, the pattern that is detected isindicative of a new road that is not currently included in the map. Assuch, a new road corresponding to the detected pattern is added to themap via the map data model. Further, a degree of confidence for the newroad may be computed based on frequency of use, how recently the newroad has been used, or the like. In addition, a name for the new roadmay be suggested based on the speed at which users have traveled on thenew road, how the new road is related to surrounding roads asrepresented by the map data model, or the like.

Those skilled in the art will appreciate the scope of the presentinvention and realize additional aspects thereof after reading thefollowing detailed description of the preferred embodiments inassociation with the accompanying drawing figures.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

The accompanying drawing figures incorporated in and forming a part ofthis specification illustrate several aspects of the invention, andtogether with the description serve to explain the principles of theinvention.

FIG. 1 illustrates a system for providing crowd-sourced map updates andcrowd-sourced alternate route recommendations according to oneembodiment of the present disclosure;

FIG. 2 illustrates the operation of the system of FIG. 1 to track thelocations of users of the mobile location-aware devices according to oneembodiment of the present disclosure;

FIG. 3 is a flow chart illustrating a process for providingcrowd-sourced map updates according to one embodiment of the presentdisclosure;

FIG. 4 is a more detailed flow chart illustrating a process forproviding crowd-sourced map updates according to one embodiment of thepresent disclosure;

FIG. 5 is a flow chart illustrating a process for detecting a patternindicative of a new road according to one embodiment of the presentdisclosure;

FIG. 6 illustrates an exemplary bounding region utilized during thepattern detection process of FIG. 5 according to one embodiment of thepresent disclosure;

FIG. 7 illustrates an exemplary Graphical User Interface (GUI) forpresenting a new road and a degree of confidence for the new road to auser according to one embodiment of the present disclosure;

FIG. 8 illustrates the operation of the system of FIG. 1 to providecrowd-sourced alternate route recommendations according to oneembodiment of the present disclosure;

FIG. 9 is a flow chart illustrating a process for generatingcrowd-sourced alternate route recommendations according to oneembodiment of the present disclosure;

FIG. 10 is a block diagram of the server of FIG. 1 according to oneembodiment of the present disclosure;

FIG. 11 is a block diagram of one of the mobile location-aware devicesof FIG. 1 according to one embodiment of the present disclosure; and

FIG. 12 is a block diagram of a computing device hosting the third-partymap function of FIG. 1 according to one embodiment of the presentdisclosure.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The embodiments set forth below represent the necessary information toenable those skilled in the art to practice the invention and illustratethe best mode of practicing the invention. Upon reading the followingdescription in light of the accompanying drawing figures, those skilledin the art will understand the concepts of the invention and willrecognize applications of these concepts not particularly addressedherein. It should be understood that these concepts and applicationsfall within the scope of the disclosure and the accompanying claims.

FIG. 1 illustrates a system 10 for providing passive crowd-sourced mapupdates, passive crowd-sourced alternate route recommendations, or bothaccording to one embodiment of the present disclosure. As illustrated,the system 10 includes a server 12 and a number of mobile location-awaredevices 14-1 through 14-N having associated users 16-1 through 16-N. Theserver 12 and the mobile location-aware devices 14-1 through 14-N areconnected via a network 18. The network 18 is preferably a publiclyaccessible distributed network such as the Internet. In addition, inthis embodiment, the system 10 may also include a third-party mapfunction 20.

The server 12 is a physical server. Note, however, that while only asingle server 12 is illustrated for clarity and ease of discussion, thesystem 10 may include multiple servers 12 that operate in acollaborative manner for purposes of load-sharing and/or redundancy. Theserver 12 includes a location tracking function 22, a map updatingfunction 24, and an alternate route recommendation function 26, each ofwhich is preferably implemented in software but is not limited thereto.In addition, the server 12 includes a map data model 28 and a locationtracking repository 30. The location tracking function 22 generallyoperates to receive location updates from the mobile location-awaredevices 14-1 through 14-N defining locations of the users 16-1 through16-N over time and to store corresponding data in the location trackingrepository 30. Note that while the description herein refers to thetracking of the locations of the users 16-1 through 16-N, as usedherein, the locations of the users 16-1 through 16-N is synonymous withthe locations of the mobile location-aware devices 14-1 through 14-N.The data stored in the location tracking repository 30 may include alocation history for each of the users 16-1 through 16-N or anonymizedlocation histories that anonymously record the locations of the users16-1 through 16-N. Using the user 16-1 of the mobile location-awaredevice 14-1 as an example, for each location update received from themobile location-aware device 14-1 for the user 16-1, the locationhistory for the user 16-1 includes the data from the location update(i.e., location and, optionally, a time-stamp, direction of travel,and/or speed of travel). Alternatively, the location history for theuser 16-1 may include a number of vectors in the form of <start, stop,time-stamp, direction, speed> derived from the location updates receivedfrom the mobile location-aware device 14-1 for the user 16-1.

In another embodiment, anonymized location histories are stored in thelocation tracking repository 30. More specifically, again using the user16-1 of the mobile location-aware device 14-1 as an example, thelocation history of the user 16-1 may be periodically persisted in thelocation tracking repository 30 as an anonymous location history. Theanonymous location history is preferably a location history record ordata object that has a new or unique identifier that is not tied back tothe user 16-1 or the mobile location-aware device 14-1. For example, ata desired periodic time interval (e.g., hourly, daily, weekly, or thelike), the location history of the user 16-1 may be persisted as ananonymous location history that is not tied back to the user 16-1. Atthe end of each periodic time interval, the location history of the user16-1 is persisted as a new anonymous location history. Further, eachtime the location history of the user 16-1 is persisted as an anonymouslocation history, all of the location data (i.e., previous locationsand, if any, time-stamps, directions of travel, and/or speed of travel)may be removed from the location history of the user 16-1.

The map updating function 24 generally operates to analyze the data inthe location tracking repository 30 that reflects the locations of theusers 16-1 through 16-N of the mobile location-aware devices 14-1through 14-N over time in order to detect patterns that are indicativeof updates that should be made to a map defined by the map data model28. The map data model 28 is generally data that defines a map of ageographic area (e.g., North America, the United States of America,North Carolina, or the like). For instance, the map data model 28 may beGeographic Information Systems (GIS) data that defines a map for ageographic area. As discussed below in detail, in the preferredembodiment, the map updating function 24 operates to detect patterns ofmovement of the users 16-1 through 16-N of the mobile location-awaredevices 14-1 through 14-N that are indicative of new roads that shouldbe added to the map defined by the map data model 28. However, in asimilar manner, the map updating function 24 may additionally oralternatively detect other changes that should be made to the map suchas, for example, temporary or permanent road closures. For instance, theabsence of movement of the users 16-1 through 16-N of the mobilelocation-aware devices 14-1 through 14-N over a particular road in themap for at least a threshold amount of time may be used as a detectionthat the road is closed.

The alternate route recommendation function 26 generally operates torecommend alternate routes to the users 16-1 through 16-N of the mobilelocation-aware devices 14-1 and 14-N and the third-party map function 20based on the data in the location tracking repository 30. Morespecifically, as discussed below, the alternate route recommendationfunction 26 receives a request for alternate routes from a requestor,where the requestor may be one of the mobile location-aware devices 14-1through 14-N or the third-party map function 20. The request identifiesa desired start location and a desired stop location. The alternateroute recommendation function 26 then uses the data in the locationtracking repository 30 to identify a number of different routespreviously taken by the users 16-1 through 16-N of the mobilelocation-aware devices 14-1 through 14-N from the desired start locationto the desired stop location. One or more of the identified routes arethen returned to the requestor as recommended alternate routes.

The mobile location-aware devices 14-1 through 14-N are generally anytype of user devices that are enabled to determine the locations of theusers 16-1 through 16-N and provide location updates for the users 16-1through 16-N to the server 12 via the network 18. For example, each ofthe mobile location-aware devices 14-1 through 14-N may be a personalnavigation device permanently installed in an automobile, a portablepersonal navigation device similar to those manufactured and sold byGarmin or TomTom, a mobile smart phone providing personal navigationdevice functionality such as an Apple® iPhone having a softwareapplication providing personal navigation device functionality, or thelike. As illustrated, the mobile location-aware devices 14-1 through14-N include personal navigation functions 32-1 through 32-N, locationreporting functions 34-1 through 34-N, and Global Positioning System(GPS) receivers 36-1 through 36-N. In addition, in this embodiment, themobile location-aware devices 14-1 through 14-N include map data models38-1 through 38-N. Each of the map data models 38-1 through 38-N is acopy of the map data model 28 of the server 12 or a subset of the mapdata model 28 defining a portion of the map for a relevant geographicarea. However, the present disclosure is not limited thereto. In analternative embodiment, the mobile location-aware devices 14-1 through14-N obtain map data from the server 12 as needed.

Using the mobile location-aware device 14-1 as an example, the personalnavigation function 32-1 may be implemented in software, hardware, or acombination thereof. The personal navigation function 32-1 generallyoperates in a manner similar to a traditional personal navigationdevice. More specifically, the personal navigation function 32-1provides turn-by-turn directions to the user 16-1 in order to navigatethe user 16-1 from a desired start location to a desired stop location.The personal navigation function 32-1 may also provide additionalfeatures such as Point-of-Interest (POI) lookup, current trafficconditions, or the like. The location reporting function 34-1 generallyoperates to provide location updates for the user 16-1 to the server 12.

The third-party map function 20 may be implemented in hardware,software, or a combination thereof. For example, the third-party mapfunction 20 may be a software application hosted by a physical server orfarm of physical servers, a user device such as a personal computer, orthe like. In general, the third-party map function 20 provides map-basedservices to users or entities. For example, the third-party map function20 may be a web-based map service such as, or similar to, the Google®Maps service, the Bing® Maps service, the MapQuest® service, or thelike. The third-party map function 20 may interact with the server 12 toobtain map updates and/or alternate routes.

FIG. 2 illustrates the operation of the system 10 of FIG. 1 to track thelocations of the users 16-1 through 16-N according to one embodiment ofthe present disclosure. In this embodiment, tracking is performedpassively by obtaining location updates for the users 16-1 through 16-Nand storing corresponding data at the server 12. While this discussionuses the mobile location-aware device 14-1 and the user 16-1 as anexample, this discussion is equally applicable to the other mobilelocation-aware devices 14-2 through 14-N and the other users 16-2through 16-N. As illustrated, the mobile location-aware device 14-1, andmore specifically the location reporting function 34-1, first gets acurrent location of the mobile location-aware device 14-1 (step 1000).In addition to the current location, the location reporting function34-1 may get a time-stamp that defines the current time, a direction oftravel of the mobile location-aware device 14-1, and/or a speed oftravel of the mobile location-aware device 14. In the preferredembodiment, the location reporting function 34-1 gets the currentlocation and, optionally, the current time, the direction of travel,and/or the speed of travel from the GPS receiver 36-1. However, the GPSreceiver 36-1 is exemplary. Any suitable technology for determining orotherwise obtaining the current location of the mobile location-awaredevice 14-1 may be used. Next, the location reporting function 34-1 ofthe mobile location-aware device 14-1 sends a location update to theserver 12 (step 1002). The location update includes the current locationof the user 16-1, which is the current location of the mobilelocation-aware device 14-1 obtained from the GPS receiver 36-1. Inaddition, the location update may obtain a time-stamp defining the timeat which the current location was obtained (i.e., the current time), thedirection of travel of the mobile location-aware device 14-1 as thedirection of travel of the user 16-1, and/or the speed of travel of themobile location-aware device 14-1 as the speed of travel of the user16-1.

Upon receiving the location update, the location tracking function 22stores data in the location tracking repository 30 corresponding to thelocation update (step 1004). In one embodiment, the location trackingrepository 30 includes a location history for each of the users 16-1through 16-N. As such, in this embodiment, the location update, or morespecifically the data included in the location update, is stored in alocation history of the user 16-1 maintained in the location trackingrepository 30. Alternatively, the location update may be processed toprovide a vector from the last location of the user 16-1 to the currentlocation of the user 16-1, where the vector may be <start location, stoplocation, time-stamp, direction, speed>. In another embodiment, asdiscussed above, the location tracking function 22 stores anonymizedlocation histories. More specifically, the location tracking function 22stores location histories for each of the users 16-1 through 16-N.However, periodically (e.g., hourly, daily, weekly, or the like), thelocation tracking function 22 persists the location histories of theusers 16-1 through 16-N as anonymous location histories that are nottied back to the users 16-1 through 16-N and removes the location data(i.e., the previous locations and/or corresponding time-stamps, speedsof travel, and/or directions of travel, or previous vectors) from thelocation histories of the users 16-1 through 16-N. Anonymization may beperformed as a background process. Alternatively, anonymization may betriggered by receipt of location updates. Thus, upon receiving thelocation update from the mobile location-aware device 14-1, the locationtracking function 22 may store the location update in the locationhistory of the user 16-1 and then determine if it is time to anonymizethe location history of the user 16-1. If so, the location trackingfunction 22 removes the location updates from the location history ofthe user 16-1 and stores the location updates as an anonymous locationhistory that is not tied back to the user 16-1 or the mobilelocation-aware device 14-1. Note that the most recent location update,most recent vector, or current location of the user 16-1 may be retainedin the location history of the user 16-1 after anonymization isperformed.

In the same manner, the other mobile location-aware devices 14-2 through14-N get their current locations and send corresponding location updatesto the server 12 (steps 1006 and 1008). In response, the locationtracking function 22 stores corresponding data in the location trackingrepository 30 for the users 16-2 through 16-N (step 1010). Asillustrated, this process continues such that the mobile location-awaredevices 14-1 through 14-N continue to send location updates for theusers 16-1 through 16-N to the server 12 over time and correspondingdata is stored in the location tracking repository 30 (steps 1012through 1022).

FIG. 3 illustrates the operation of the map updating function 24 of theserver 12 according to one embodiment of the present disclosure. First,the map updating function 24 detects a travel pattern that is indicativeof a new road that is not included on the map defined by the map datamodel 28 (step 2000). More specifically, the map updating function 24analyzes the data in the location tracking repository 30 as compared tothe map data model 28 to detect a pattern of movement of the users 16-1through 16-N that is indicative of a new road that is not included onthe map defined by the map data model 28. In general, a patternindicative of a new road is a pattern of consistent and frequent travelof the users 16-1 through 16-N, or more specifically at least a subsetof the users 16-1 through 16-N, in a manner that is consistent withtravel along a road. In addition, the map updating function 24 maycompute a degree of confidence for the new road. The degree ofconfidence is preferably a function of frequency of use and how recentlythe new road has been used.

Once the new road is detected, the map updating function 24 updates themap to include the new road (step 2002). More specifically, the mapupdating function 24 adds data defining the new road to the map datamodel 28. In addition, the map updating function 24 may add the degreeof confidence for the new road to the map data model 28. At this point,in one embodiment, the map updating function 24 sends an update to themap data model 28 for the new road and the degree of confidence for thenew road, if any, to one or more of the mobile location-aware devices14-1 through 14-N. Those mobile location-aware devices 14-1 through 14-Nthat receive the update then add the update to their map data models38-1 through 38-N. In addition, the map updating function 24 may sendthe update for the map data model 28 to the third-party map function 20.In an alternative embodiment, rather than immediately updating the mapdata model 28, the map updating function 24 may flag the update orotherwise send an alert regarding the update to an owner or editor ofthe map represented by the map data model 28 for verification before themap is officially updated.

FIG. 4 is a more detailed flow chart illustrating the operation of theserver 12 to update the map according to one embodiment of the presentdisclosure. In this embodiment, the location tracking function 22receives a location update (step 3000). For this discussion, thelocation update is received from the mobile location-aware device 14-1for the user 16-1. In response, the location tracking function 22generates and stores a vector from a previous location of the user 16-1to a current location of the user 16-1 identified in the location update(step 3002). The previous location of the user 16-1 is the location ofthe user 16-1 identified in the immediately preceding location updatereceived from the mobile location-aware device 14-1. Again, the vectoris preferably in the form of <start location, stop location, time-stamp,direction, speed> but is not limited thereto. “Start location” is theprevious location of the user 16-1 identified by the immediatelypreceding location update for the user 16-1, “stop location” is thecurrent location of the user 16-1 identified in the location update,time-stamp is the timestamp from the corresponding location update,direction is the direction of travel from the location update, and speedis the speed of travel from the location update.

Next, the map updating function 24 determines whether the user 16-1 iscurrently on a crowd-sourced road (step 3004). As used herein, acrowd-sourced road is a road previously added to the map by the mapupdating function 24 based on detected patterns of travel, or movement,of the users 16-1 through 16-N. Note, however, that a crowd-sourced roadmay be promoted to a permanent road in the map data model 28 when, forexample, the crowd-sourced road is verified by an operator of the server12 (i.e., a person) or the degree of confidence of the crowd-sourcedroad reaches a predefined threshold (e.g., 90% or 100%). The mapupdating function 24 determines whether the user 16-1 is currently on acrowd-sourced road by comparing the current location of the user 16-1 tothe map data model 28. If the user 16-1 is on a crowd-sourced road, themap updating function 24 updates the degree of confidence of thecrowd-sourced road (step 3006). Again, the degree of confidence ispreferably a function of frequency of use of the crowd-sourced road andhow recently the crowd-sourced road has been used. The more frequentlyand recently the crowd-sourced road has been used by the users 16-1through 16-N, the higher the degree of confidence for the crowd-sourcedroad. At this point, the process returns to step 3000 and is repeatedfor the next received location update.

If the user 16-1 is not on a crowd-sourced road, the map updatingfunction 24 determines whether the user 16-1 is currently on a permanentroad (step 3008). As used herein, a permanent road is a road that wasoriginally in the map or a crowd-sourced road added by the map updatingfunction 24 that has been verified or that has a degree of confidenceequal to or greater than a predefined threshold degree of confidence. Ifthe user 16-1 is currently on a permanent road, the process returns tostep 3000 and is repeated for the next received location update. If theuser 16-1 is neither on a crowd-sourced road nor a permanent road, themap updating function 24 determines whether a predefined number (M) oflocation updates have been received for the user 16-1 since the user16-1 was last determined to be on a road (i.e., a permanent road or acrowd-sourced road) (step 3010). The number M may be any integer greaterthan or equal to one (1). If less than M location updates have beenreceived for the user 16-1 since the user 16-1 was last on a road, theprocess returns to step 3000 and is repeated for the next receivedlocation update.

If M location updates have been received for the user 16-1 since theuser 16-1 was last on a road, the map updating function 24 performs apattern detection process for the last M vectors in the location historyof the user 16-1 (step 3012). Note that if vectors are not used, thepattern detection process is performed for the last M entries in thelocation history of the user 16-1. In general, the map updating function24 obtains the last M vectors from the location history of the user16-1. In addition, the map updating function 24 obtains other vectorsfrom the location histories stored in the location tracking repository30 that have start and stop locations in the same vicinity as the startand stop locations of one or more of the last M vectors for the user16-1. These vectors are then analyzed to determine whether there is apattern of travel or movement that is indicative of a new road. If so,the map updating function 24 updates the map data model 28 with datadefining the new road. In addition, map updates may be sent to one ormore of the mobile location-aware devices 14-1 through 14-N and/or thethird-party map function 20. At this point, the process returns to step3000 and is repeated for the next received location update.

FIG. 5 is a flow chart illustrating step 3012 of FIG. 4 in more detailaccording to one embodiment of the present disclosure. First, the mapupdating function 24 gets the last M vectors from the location historyof the user 16-1 stored in the location tracking repository 30 (step4000). The map updating function 24 then establishes a bounding regionfor the last M vectors (step 4002). The bounding region is generally ageographic region that encompasses the start and stop locations for thelast M vectors for the user 16-1. Preferably, the bounding region isestablished such that the bounding region is, or is approximately, ageographic region defined by a maximum distance (D) from the last Mvectors of the user 16-1, as illustrated in FIG. 6.

Returning to FIG. 5, the map updating function 24 then gets all knownvectors from the location tracking repository 30 having start locationsand stop locations located within the bounding region for the last Mvectors of the user 16-1 (step 4004). Alternatively, the map updatingfunction 24 may get a subset of all known vectors from the locationtracking repository 30 having start locations and stop locations locatedwithin the bounding region for the last M vectors of the user 16-1, suchas all known vectors from the location tracking repository 30 havingstart locations and stop locations within the bounding region for thelast M vectors of the user 16-1 that have time-stamps within a definedtime window. The defined time window may be a relative time window suchas, for example, the last month.

The map updating function 24 then analyzes the known vectors obtained instep 4004 and, optionally, the last M vectors for the user 16-1 todetermine whether there is a pattern of travel or movement that isindicative of a new road (step 4006). For example, the known vectors maybe filtered to remove those vectors having directions and, optionally,speeds that are inconsistent with the directions and speeds of the lastM vectors for the user 16-1. More specifically, for each known vector,the map updating function 24 may determine to filter the known vector ifthe direction and optionally speed of the known vector are more than apredefined amount of deviation from the direction and optionally speedof a nearest one of the last M vectors for the user 16-1 (i.e., the oneof the last M vectors having a start location and/or stop location thatis closest to the start location and/or stop location, respectively, ofthe known vector). If the direction and, if used, the speed of the knownvector are within the predefined amount of deviation from the directionand, if used, the speed of the nearest one of the last M vectors for theuser 16-1, then the known vector is not filtered. Once filtering iscomplete, the remaining known vectors, which are referred to herein asthe filtered vectors, are counted. If the number of filtered vectors isgreater than a predefined threshold number of vectors, then a pattern isdetected. Note that this process for detecting a pattern is exemplaryand is not intended to limit the scope of the present disclosure. Anysuitable pattern recognition technique may be used.

Once the analysis is complete, the map updating function 24 determineswhether a pattern that is indicative of a new road has been detected(step 4008). If not, the process ends. If so, the map updating function24 computes a path for the new road that corresponds to the detectedpattern and, optionally, a confidence factor for the new road (step4010). In one embodiment, the bounding region for the last M vectors forthe user 16-1 is divided into a series of sub-regions. For example, eachsub-region may include one of the last M vectors for the user 16-1.Then, for each sub-region, the map updating function 24 may identifyvectors from the filtered vectors that have start locations within thatsub-region and then combine (e.g., average) the start locations for theidentified vectors to provide a combined point for the sub-region. Oncecomplete, the combined points for the sub-regions define the path forthe new road. Again, the degree of confidence for the new road may becomputed as a function of frequency of use by the users 16-1 through16-N and how recently the new road has been used by the users 16-1through 16-N.

In addition, the map updating function 24 may suggest a name for the newroad. The map updating function 24 may suggest a name of the road basedon detected patterns in the movement of users that have traveled the newroad, surrounding roads in the map data model 28, or a combinationthereof. The detected patterns in movement may be, for example, anaverage speed of the users that have traveled the road, start and stoppatterns, patterns indicating that the new road extends from an existingroad, patterns indicating that the new road merges into an existingroad, patterns indicating that the new road extends from and merges backinto an existing road, or the like. For example, the average speed atwhich users have traveled the new road may be used to determine whetherthe new road is likely to be an Interstate Highway, a city street, orthe like. Similarly, start and stop patterns may be used to determinethat the new road is a city street. In addition or alternatively, thepath of the new road may be analyzed with respect to surrounding roadsto determine whether the new road is an extension of an existing road,an alternate version of an existing road (e.g., Alternate I-40 as analternate for I-40).

Lastly, the map updating function 24 updates the map data model 28 toinclude data defining the new road (step 4012). In addition, acorresponding update may be provided to one or more of the mobilelocation-aware devices 14-1 through 14-N and/or the third-party mapfunction 20. At this point, the process ends. Again, in an alternativeembodiment, rather than immediately updating the map data model 28, themap updating function 24 may flag the update or otherwise send an alertregarding the update to an owner or editor of the map represented by themap data model 28 for verification before the map is officially updated.

FIG. 7 illustrates an exemplary Graphical User Interface (GUI) 40 forpresenting a map including a crowd-sourced map update provided by themap updating function 24 of the server 12 according to one embodiment ofthe present disclosure. As illustrated, the GUI 40 generally presents amap, which is preferably a portion of the map defined by the map datamodel 28 of the server 12. A new road 42 detected by the map updatingfunction 24 of the server 12 based on a detected travel pattern of theusers 16-1 through 16-N is shown in the GUI 40. In one embodiment, anopacity of the new road 42 in the GUI 40 corresponds to a degree ofconfidence for the new road 42 computed by the map updating function 24.In addition or alternatively, the GUI 40 may include a window providinginformation for the new road 42 such as, for example, the degree ofconfidence for the new road 42 and a likely, or suggested name, of thenew road 42.

In this example, since the new road 42 diverges from I-40 and rejoinsI-40, the map updating function 24 determines that the new road 42 islikely an Alternate I-40. More specifically, based on the map data model28, the map updating function 24 knows that I-40 is an interstate andthat characteristic speeds on I-40 are 55 to 80 mph. The map updatingfunction 24 detects a large number of users diverging from I-40 onto thenewly detected road at speeds that are characteristic of merging ontoanother highway. Then, ten miles later, the map updating function 24detects a large number of users diverging from this newly detected roadback onto I-40 at a speed that is characteristic of merging onto anotherhighway. From these characteristic and passively detected inputs, themap updating function 24 is enabled to determine that the newly detectedroute is likely to be an “Alternate” or “Business Bypass” of I-40 andtherefore suggest “Alternate I-40” as a name for the newly detectedroad.

FIG. 8 illustrates the operation of the system 10 to recommend alternateroutes according to one embodiment of the present disclosure. Asillustrated, first, the mobile location-aware device 14-1 sends analternate route request to the server 12 (step 5000). Note that whilethe mobile location-aware device 14-1 is the requestor in thisdiscussion, the requestor may alternatively be one of the other mobilelocation-aware devices 14-2 through 14-N or the third-party map function20. The alternate route request identifies a desired start location anda desired stop location. More specifically, in one embodiment, thepersonal navigation function 32-1 sends the alternate route request tothe server 12 either automatically in response to a request from theuser 16-1 to be navigated from the desired start location to the desiredstop location or in response to an explicit request for alternate routesfrom the user 16-1.

In response to receiving the alternate route request, the alternateroute recommendation function 26 of the server 12 generates one or morealternate routes from the desired start location to the desired stoplocation (step 5002). In general, the alternate route recommendationfunction 26 utilizes data in the location tracking repository 30 toidentify routes previously taken by the users 16-1 through 16-N from thedesired start location to the desired stop location. The alternate routerecommendation function 26 then selects one or more of the identifiedroutes as alternate routes to recommend, and then returns the alternateroutes to the mobile location-aware device 14-1 (step 5004). Thepersonal navigation function 32-1 of the mobile location-aware device14-1 then utilizes the alternate routes (step 5006). For example, thepersonal navigation function 32-1 may display the alternate routes tothe user 16-1 and enable the user 16-1 to select one of the alternateroutes to use. Note that, in an alternative embodiment, rather thanimmediately sending the alternate routes to the mobile location-awaredevice 14-1, the recommended routes may be verified, such as by an owneror editor of the map represented by the map data model 28, before therecommended routes are sent to the mobile location-aware device 14-1.

FIG. 9 is a flow chart illustrating the operation of the alternate routerecommendation function 26 of the server 12 in more detail according toone embodiment of the present disclosure. First, the alternate routerecommendation function 26 receives an alternate route request thatidentifies a desired start location and a desired stop location (step6000). In response, the alternate route recommendation function 26identifies users from the users 16-1 through 16-N that have traveledfrom the desired start location to the desired stop location (step6002). Note that the users that have traveled from the desired startlocation to the desired stop location preferably include users that havestarted at the desired start location and ended at the desired stoplocation as well as users that have traveled from or through the desiredstart location to or through the desired stop location. Optionally, theidentified users may be only those users that have traveled from thedesired start location to the desired stop location during a desiredtime window. The desired time window may be a reoccurring time windowcorresponding to a current time of day (e.g., 10 AM to Noon), a currentday of the week (Monday, Weekday, or Weekend), a combination of acurrent or defined time of day and day of week (e.g., Monday from 10 AMto Noon or Weekdays from 10 AM to Noon), or the like.

The alternate route recommendation function 26 then determines one ormore different routes taken by the identified users from the desiredstart location to the desired stop location (step 6004). Morespecifically, for each of the identified users, the alternate routerecommendation function 26 determines a route taken by the identifieduser from the desired start location to the desired stop location. Theroutes taken by the identified users are compared to one another todetermine a number of different routes taken by the identified usersfrom the desired start location to the desired stop location.

Next, the alternate route recommendation function 26 determines one ormore characteristics for each of the different route(s) (step 6006). Foreach of the different routes, the one or more characteristics for thatroute may include, for example, a number of the identified users thattook that route, an average travel time for that route, an averagetravel time for that route for desired time window, or the like. Theaverage travel time for a route is determined based on actual traveltimes for that route for corresponding users determined based on thelocation histories of those users. Similarly, the average travel timefor a route for the desired time window is determined based on actualtravel times for that route for corresponding users that traveled thatroute during the desired time window. The desired time window may be areoccurring time window corresponding to a current time of day (e.g., 10AM to Noon), a current day of the week (Monday, Weekday, or Weekend), acombination of a current or defined time of day and day of week (e.g.,Monday from 10 AM to Noon or Weekdays from 10 AM to Noon), or the like.The alternate route recommendation function 26 then returns the one ormore different routes and the characteristics of the one or moredifferent routes to the requestor as alternate route recommendations(step 6008). Note that either prior to step 6006 or before returning therecommendations in step 6008, the different routes identified in step6004 may be filtered or otherwise processed to remove unwanted routes.For example, filtering may be performed to remove a particular routethat has already been provided to the user 16-1 (e.g., an optimal routethat has already been generated by the personal navigation function 32-1using a traditional route generation technique).

FIG. 10 is a block diagram of the server 12 according to one embodimentof the present disclosure. As illustrated, the server 12 includes acontroller 46 connected to memory 48, one or more secondary storagedevices 50, and a communication interface 52 by a bus 54 or similarmechanism. The controller 46 is a microprocessor, digital ApplicationSpecific Integrated Circuit (ASIC), Field Programmable Gate Array(FPGA), or the like. In this embodiment, the controller 46 is amicroprocessor, and the location tracking function 22, the map updatingfunction 24, and the alternate route recommendation function 26 areimplemented in software and stored in the memory 48 for execution by thecontroller 46. Further, the map data model 28 and the location trackingrepository 30 may be stored in the one or more secondary storage devices50. The secondary storage devices 50 are digital data storage devicessuch as, for example, one or more hard disk drives. The communicationinterface 52 is a wired or wireless communication interface thatcommunicatively couples the server 12 to the network 18 (FIG. 1). Forexample, the communication interface 52 may be an Ethernet interface,local wireless interface such as a wireless interface operatingaccording to one of the suite of IEEE 802.11 standards, or the like.

FIG. 11 is a block diagram of the mobile location-aware device 14-1according to one embodiment of the present disclosure. This discussionis equally applicable to the other mobile location-aware devices 14-2through 14-N. As illustrated, the mobile location-aware device 14-1includes a controller 56 connected to memory 58, a communicationinterface 60, one or more user interface components 62, and the GPSreceiver 36-1 by a bus 64 or similar mechanism. The controller 56 is amicroprocessor, digital ASIC, FPGA, or the like. In this embodiment, thecontroller 56 is a microprocessor and the location reporting function34-1 and, in some implementations, the personal navigation function 32-1are implemented in software and stored in the memory 58 for execution bythe controller 56. In this embodiment, the GPS receiver 36-1 is ahardware component. The communication interface 60 is a wirelesscommunication interface that communicatively couples the mobilelocation-aware device 14-1 to the network 18 (FIG. 1). For example, thecommunication interface 60 may be a local wireless interface such as awireless interface operating according to one of the suite of IEEE802.11 standards, a mobile communications interface such as a cellulartelecommunications interface, or the like. The one or more userinterface components 62 include, for example, a touchscreen, a display,one or more user input components (e.g., a keypad), a speaker, or thelike, or any combination thereof.

FIG. 12 is a block diagram of a computing device 66 that hosts thethird-party map function 20 according to one embodiment of the presentdisclosure. As illustrated, the computing device 66 includes acontroller 68 connected to memory 70, one or more secondary storagedevices 72, a communication interface 74, and one or more user interfacecomponents 76 by a bus 78 or similar mechanism. The controller 68 is amicroprocessor, digital ASIC, FPGA, or the like. In this embodiment, thecontroller 68 is a microprocessor, and the third-party map function 20is implemented in software and stored in the memory 70 for execution bythe controller 68. The one or more secondary storage devices 72 aredigital storage devices such as, for example, one or more hard diskdrives. The communication interface 74 is a wired or wirelesscommunication interface that communicatively couples the computingdevice 66 to the network 18 (FIG. 1). For example, the communicationinterface 74 may be an Ethernet interface, local wireless interface suchas a wireless interface operating according to one of the suite of IEEE802.11 standards, a mobile communications interface such as a cellulartelecommunications interface, or the like. The one or more userinterface components 76 include, for example, a touchscreen, a display,one or more user input components (e.g., a keypad), a speaker, or thelike, or any combination thereof.

Those skilled in the art will recognize improvements and modificationsto the preferred embodiments of the present invention. All suchimprovements and modifications are considered within the scope of theconcepts disclosed herein and the claims that follow.

What is claimed is:
 1. A method comprising: tracking locations of aplurality of users of a plurality of mobile location-aware devices overtime; receiving an alternate route request from a requestor, thealternate route request identifying a desired start location and adesired stop location; identifying one or more users of the plurality ofusers that have traveled from the desired start location to the desiredstop location based on the locations of the plurality of users of theplurality of mobile location-aware devices, wherein the one or moreusers of the plurality of users includes users other than the requestor;determining, by a processor, one or more different routes taken by theone or more users from the desired start location to the desired stoplocation based on the locations of the one or more users; and providing,by the processor, at least one of the one or more different routes takenby the one or more users from the desired start location to the desiredstop location to the requestor as at least one recommended alternateroute.
 2. The method of claim 1 wherein identifying one or more users ofthe plurality of users that have traveled from the desired startlocation to the desired stop location comprises identifying one or moreusers of the plurality of users that have traveled from the desiredstart location to the desired stop location during a desired timewindow.
 3. The method of claim 2 wherein the desired time window is areoccurring time window corresponding to at least one of a groupconsisting of: a current time of day and a current day of the week. 4.The method of claim 1 further comprising: determining, for eachdifferent route of the at least one of the one or more different routes,a characteristic of the different route; and providing thecharacteristic of each different route to the requestor.
 5. The methodof claim 4 wherein the characteristic of the different route is a numberof users of the plurality of users that have traveled the differentroute.
 6. The method of claim 4 wherein the characteristic of thedifferent route is an average travel time for the different routedetermined based on actual travel times of users of the plurality ofusers that have traveled the different route.
 7. The method of claim 4wherein the characteristic of the different route is an average traveltime for the different route determined based on actual travel times ofusers of the plurality of users that have traveled the different routeduring a desired time window.
 8. The method of claim 7 wherein thedesired time window is a reoccurring time window corresponding to atleast one of a group consisting of: a current time of day and a currentday of the week.
 9. A server comprising: a communication interfacecommunicatively coupling the server to a plurality of mobilelocation-aware devices via a network; and a controller associated withthe communication interface and adapted to: track locations of aplurality of users of the plurality of mobile location-aware devicesover time; receive an alternate route request from a requestor, thealternate route request identifying a desired start location and adesired stop location; identify one or more users of the plurality ofusers that have traveled from the desired start location to the desiredstop location based on the locations of the plurality of users of theplurality of mobile location-aware devices, wherein the one or moreusers of the plurality of users includes users other than the requestor;determine one or more different routes taken by the one or more usersfrom the desired start location to the desired stop location based onthe locations of the one or more users; and provide at least one of theone or more different routes taken by the one or more users from thedesired start location to the desired stop location to the requestor asat least one recommended alternate route.
 10. The server of claim 9wherein in order to identify one or more users of the plurality of usersthat have traveled from the desired start location to the desired stoplocation, the controller is further adapted to identify one or moreusers of the plurality of users that have traveled from the desiredstart location to the desired stop location during a desired timewindow.
 11. The server of claim 10 wherein the desired time window is areoccurring time window corresponding to at least one of a groupconsisting of: a current time of day and a current day of the week. 12.The server of claim 9 wherein the controller is further adapted to:determine, for each different route of the at least one of the one ormore different routes, a characteristic of the different route; andprovide the characteristic of each different route to the requestor. 13.The server of claim 12 wherein the characteristic of the different routeis a number of users of the plurality of users that have traveled thedifferent route.
 14. The server of claim 12 wherein the characteristicof the different route is an average travel time for the different routedetermined based on actual travel times of users of the plurality ofusers that have traveled the different route.
 15. The server of claim 12wherein the characteristic of the different route is an average traveltime for the different route determined based on actual travel times ofusers of the plurality of users that have traveled the different routeduring a desired time window.
 16. The server of claim 15 wherein thedesired time window is a reoccurring time window corresponding to atleast one of a group consisting of: a current time of day and a currentday of the week.
 17. A non-transitory computer-readable medium storingsoftware for instructing a controller of a server to: track locations ofa plurality of users of a plurality of mobile location-aware devicesover time; receive an alternate route request from a requestor, thealternate route request identifying a desired start location and adesired stop location; identify one or more users of the plurality ofusers that have traveled from the desired start location to the desiredstop location based on the locations of the plurality of users of theplurality of mobile location-aware devices, wherein the one or moreusers of the plurality of users includes users other than the requestor;determine one or more different routes taken by the one or more usersfrom the desired start location to the desired stop location based onthe locations of the one or more users; and provide at least one of theone or more different routes taken by the one or more users from thedesired start location to the desired stop location to the requestor asat least one recommended alternate route.
 18. The non-transitorycomputer-readable medium of claim 17 wherein in order to identify one ormore users of the plurality of users that have traveled from the desiredstart location to the desired stop location, the software furtherinstructs the controller to identify one or more users of the pluralityof users that have traveled from the desired start location to thedesired stop location during a desired time window.
 19. Thenon-transitory computer-readable medium of claim 18 wherein the desiredtime window is a reoccurring time window corresponding to at least oneof a group consisting of: a current time of day and a current day of theweek.
 20. The non-transitory computer-readable medium of claim 17wherein the software further instructs the controller to: determine, foreach different route of the at least one of the one or more differentroutes, a characteristic of the different route; and provide thecharacteristic of each different route to the requestor.
 21. Thenon-transitory computer-readable medium of claim 20 wherein thecharacteristic of the different route is a number of users of theplurality of users that have traveled the different route.
 22. Thenon-transitory computer-readable medium of claim 20 wherein thecharacteristic of the different route is an average travel time for thedifferent route determined based on actual travel times of users of theplurality of users that have traveled the different route.
 23. Thenon-transitory computer-readable medium of claim 20 wherein thecharacteristic of the different route is an average travel time for thedifferent route determined based on actual travel times of users of theplurality of users that have traveled the different route during adesired time window.
 24. The non-transitory computer-readable medium ofclaim 23 wherein the desired time window is a reoccurring time windowcorresponding to at least one of a group consisting of: a current timeof day and a current day of the week.